Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/cat/cat-minutes-92nov.txt

Text File | 1993-02-17 | 10.1 KB | 253 lines

Editor's Note: Minutes received 11/3/92

CURRENT_MEETING_REPORT_



Reported by John Linn/DEC

Minutes of the Common Authentication Technology Working Group (CAT)

The CAT Working Group met for one session at the November 1992 IETF.
Primary discussion topics were:


   o Status of documents.
   o Future work items and issues.
   o Token representation and integration.
   o FTP security.


Status of Documents

Steve Crocker stated his belief that the GSS-API and associated C
bindings Internet-Drafts were ready for advancement to Proposed Standard
RFCs, and that he would recommend this action shortly.  The Kerberos V5
Internet-Draft is pending certain local and specific edits, and is to be
included in the same advancement recommendation.  Despite the fact that
Kerberos is the only CAT technology visibly under active development and
support at this time, it was still viewed as a desirable goal that
applications use CAT/GSS-API rather than mechanism-specific interfaces
so as to support future portability.

Future Work Items and Issues

Ted Ts'o led a discussion suggesting future work items and issues for
CAT. He divided client applications for authentication services into
four groups:


  1. Datagram protocols, generally (e.g., SNMP) not viewed as a good fit
     for CAT, though better suitability to other connectionless
     protocols was considered as a possibility.

  2. Store-and-forward protocols, also not viewed as a good fit for CAT.

  3. Stream protocols (e.g., Telnet, rpc, lpr, NNTP), considered by Ted
     as the best-fitting candidates for CAT usage.

  4. Multiple-stream protocols (e.g., FTP), with suitability not
     evaluated.


His list of thoughts on future work included [with editor's annotations
in square brackets]:

                                   1





   o A need for better [more complete and fully-tested] GSS-API clients
     and mechanism implementations, e.g., to implement rlogin with less
     reliance on local or mechanism-specific routines in addition to
     GSS-API.

   o Development of an easy-to-use layer overlaid atop GSS-API to embody
     token-passing, analogous to Kerberos's krb_sendauth.


Ted's list of issues and near-term action recommendations was as
follows:


   o Negotiation of mechanisms:  recognized as important in the eventual
     term, but not needed in the near term, given a presumption that
     GSS-API callers (in an environment with only a limited number of
     mechanisms in use) would not be burdened by a requirement to pass
     in explicit mechanism type specifiers.

   o Strength ranking of mechanisms:  as with negotiation, not needed at
     first.

   o Naming:  generalized translation between types not needed, but a
     canonical flat ASCII representation was desirable for ACLs, etc.
     Internationalization was recognized as an issue here, with a
     character set selection tag being requested.  The long-requested
     and as-long-frustrated desire for a unifying Internet naming
     framework also arose as an issue here.

   o Infrastructure requirements:  given that many sites don't want to
     pay the prices attendant to use of Kerberos, SPX, or similar
     cryptographic mechanisms, peer-peer key/password exchange and
     non-disclosing password systems should be considered as CAT
     mechanisms.  An issue here is the fact that such lower-function
     mechanisms don't generally authenticate principals in terms of
     global names; use of an interface facility [e.g., a name type tag]
     to distinguish local from global names is a partial approach to the
     issue.  Many lower-function mechanisms do not yield session keys
     for per-message protection as a result of authentication, but
     mechanisms with this characteristic are accommodated with existing
     interface indicators.


Availability of a Kerberos V4 GSS-API implementation would be
convenient; while some activities had been undertaken to this end in
previous years, no complete implementation compatible with current
specifications is known to exist.  The GSS-API modules within the
Kerberos V5 implementation (as of the re- cent Beta 2 release) have been
unit tested, and code exists to support all calls, but have not been
linked and tested with a sample client.  Ted Ts'o indicated that he
would like to coor- dinate with anyone interested in performing this
testing, but that he cannot himself provide the resources needed to
develop or carry out the tests in the near future; Steve Lunt expressed

                                   2





interest in this activity.

Token Representation and Integration

The present Kerberos V5 GSS-API implementation includes tagging
facilities on its tokens, but (unsurprisingly, given the order of
events) the tags do not include the object identifier recently assigned
to Kerberos by the IANA and to be included in the upcoming revision to
the Kerberos specification.  As a goal, it was agreed desirable that
applications into which authentication is being newly integrated should
use OID-identified mechanism tags.  It was noted that use of ASN.1 in
tagging should be constrained (and, in the GSS-API appendix's
recommendation, is constrained to X.509-DER) so that the use of a fully
general ASN.1 parser is not required; further clarification on the
encoding conventions and their processing requirements was requested.

Ted Ts'o suggested development of a generic ``plug-in'' authentication
protocol layered on GSS-API, to be embedded within applications which
are built over stream-oriented communications.  NNTP was specifically
cited as an example; Telnet (given the fact that it acts itself as a
sophisticated stream manager and is oriented to transfer of data
elements within options) was not considered as a customer for this
proposed technology and would be more appropriately served by calling
CAT directly.  In the ``plug-inx'' approach, a stream would be
established by the application and then handed over for use by the
authentication protocol while authentication tokens were exchanged.
Subsequent to token exchange, within which mechanism negotiation could
also be incorporated, the stream could (optionally) either be handed
back to the application or the application's communications could be
encapsulated and thereby protected by the ``plug-in'' protocol.  The
ability to reinitiate the ``plug-in'' protocol on an
already-authenticated stream, thereby accomplishing reauthentication,
was requested in discussion and considered to be supportable.

The format of CAT tokens was not perceived as a particularly hard issue
from the viewpoint of caller protocols; the prospect the token exchanges
in the course of carrying out GSS-API continuation scenarios raises
qualitatively different complexity to callers, which use of the
``plug-in'' could simplify.  It was observed that existing mechanisms
involve exchange of no more than two tokens, one from an initiator to a
target and a second returned from the target to the initiator, and that
perhaps the most likely scenario in which need for longer exchanges
might arise would be design of a ``negotiated'' mechanism in which
authentication elements were preceded by tokens transferred in order to
establish a mechanism shared between peers.

FTP Security

At the end of the meeting, Sam Sjogren led a brief discussion on
security for FTP, a topic for which he has established a discussion
group.  Interest exists in Kerberized FTP in order to eliminate
transmission of cleartext passwords across networks.  The FTP


                                   3





specification states that FTP's control connection ``follows Telnet
protocol'', but is silent about use of Telnet options on the control
connection and it was believed that at least most FTP implementations
would not accept Telnet options on an FTP control port.  The FTP
specification also states that data elements in FTP commands are usually
to be interpreted by humans, but informal communication with Jon Postel
suggests that he would not oppose the inclusion of encoded data intended
for machine interpretation (e.g., cryptographic authentication tokens)
so long as the data elements' contents were properly specified.  It was
suggested that authentication information for an FTP control connection
could be represented either through use of the Telnet authentication
option (if Telnet options are found to be supported or easily
supportable within FTP) or by direct calls to CAT and textual encoding
of CAT tokens.

In addition to security on FTP's control connection, there was also
interest in protecting the data connection, most efficiently in a block
mode.  Any such protection would need to be compatible with the variety
of transfer modes supported within FTP.

Actions

Ted Ts'o plans further work on documenting the stream-oriented
``plug-in'' overlay.

Neil Haller plans further work on integrating a lower-function
authentication mechanism, probably to be based on the S/key technology,
under the GSS-API.

John Linn plans further work on documenting token encoding conventions
and their attendant requirements.

Attendees

David Conklin            [e-mail]
Stephen Crocker          [e-mail]
Cathy Cunningham         [e-mail]
Art Dertke               [e-mail]
William Edison
Richard Graveman         [e-mail]
Neil Haller              [e-mail]
Ken Hirata               [e-mail]
Russell Housley          [e-mail]
Frank Kastenholz         [e-mail]
David Katinsky           [e-mail]
John Kunze               [e-mail]
Paul Lambert             [e-mail]
John Linn                [e-mail]
Steven Lunt              [e-mail]
Mohammad Mirhakkak       [e-mail]
Clifford Neuman          [e-mail]
Hilarie Orman            [e-mail]


                                   4





Paul Sangster            [e-mail]
Sam Schaen               [e-mail]
Sam Sjogren              [e-mail]
Tang Tang                [e-mail]
John Vollbrecht          [e-mail]
Chuck Warlick            [e-mail]
Daniel Woycke            [e-mail]



                                   5